System and method for a private and secure merchant payment system using a mobile wireless device

ABSTRACT

A secure payment system between a customer and a merchant uses a wireless device of the customer that receives a partial payment authorization record from a sales terminal of the merchant to include at least a merchant terminal identification and a payment amount to facilitate payment transaction via a customer portable wireless device from the customer to the merchant. The device has a receive sensor to receive the partial transaction record from the sales terminal and a function that activates a payment transaction function in the device. The payment function, on being activated, creates an encrypted payment data record including at least the merchant terminal identification, the payment amount, a personal code and the device identification code and transfers it over the global network to a central system. The device and the sales terminal receive from the central system a notification of the payment approval record.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is continuation of application Ser. No. 10/046,834,filed Jan. 15, 2002, and titled “A PRIVATE AND SECURE PAYMENT SYSTEM”.

FIELD OF THE INVENTION

The present invention is directed to facilitating private and securemerchant payment at a merchant sales terminal using a wireless mobiledevice of the customer.

BACKGROUND

With reference to FIG. 1, when making a payment to a merchant with thehelp of a bankcard 1000, the bankcard is swiped through a card reader1002, which is connected to the merchant computer system 1004. The cardreader reads the information from the card such as card number,expiration date, and customer name. The data read from the bankcard 1000is copied into the merchant system 1004 and is combined with the itemsbeing purchased. A third party merchant processor 1010 is used toapprove the total purchase amount by contacting an automatedclearinghouse (ACH) 1014. The ACH receives authorization from thecustomer bank 1016 and returns an authorization code. After anauthorization is obtained by the merchant system 1004 from the merchantprocessor 1010, it prints a customer receipt 1008 requiring customersignature. A paper or an electronic copy of the customer signature 1006is retained by the merchant system while a copy is given to the customer1008.

This system of payment presents many privacy and security risks to thecustomer 1020. To the customer, there is privacy risk because themerchant retains detailed data on the customer and the items beingbought and when they were bought. These data may be shared with or soldto other parties. To the customer there is a security risk as theprinted receipt 1008 contains some or all of the personal sensitivedata, which the customer has to safeguard and to properly dispose ofwhen not needed.

The merchant retains the customer sensitive data of name, card numberand signature. This presents an additional security risk in that;computer hackers and thieves may steal it. Multiplicity of data recordsis kept with many merchants as a record is created with each merchanteach time a payment transaction is conducted. Thus the customersensitive data is stored with many merchants in many paper and databaserecords. This significantly raises the probability of theft and hackingfrom the merchant paper and computer records. In FIG. 1, these privacyand security risks are shown as Privacy and Security Risk A

To the customer there is privacy risk as the customer bank 1016 isnotified which merchant a customer of the bank purchased from and whenand how much was spent on each purchase. A bank statement 1018 listingeach purchase from a merchant is created and sent to the customer 1020.The bank 1016 may sell or use the information in statement 1018 for itsown purpose. FIG. 2, an advertisement from, Wall Street Journal, Dec.19, 2001, is an illustration of how the banks and merchants may be usingthe payment information. For example it shows that a bank customerbought ski lift tickets last week 1022, in addition to many otherpersonal and private details 1024. In FIG. 1, these privacy and securityrisks are shown as Privacy and Security Risk B.

While some customers may not care that such data is kept in bank andmerchant-owned computer systems, many people, based on published studiesand stories, do care about the privacy and security of their personaldata and the details of their purchasing habits.

There is yet another security risk to the customer, as he/she has tocarry his/her bank card with him/her all the time and this is subject totheft and loss.

There are other forms of payment transactions that present similarprivacy and security risks to the customer such as, between two partiesvia a check, as the checks are imprinted with customer name, address,bank account number and other information.

In light of the above, it is an objective of the present invention tohave a payment system for the customer between a merchant and betweenprivate parties that has none of the privacy and security risks, asoutlined above.

SUMMARY

With the payment system of the present invention, a customer may conducta private and secure payment transaction: (i) with a merchant using awireless device; (ii) with a merchant using a payment card; (iii) with amerchant using a bank card; (iv) with a merchant using either a wirelessdevice, a payment card or a bank card; (v) with a private party using awireless device; and (vi) withdraw cash from an ATM machine using awireless device.

In all of these embodiments, a customer does not share his/her identity,personal sensitive data, and purchasing habits with the merchants andthe banks. In many of these embodiments, a customer need not carryhis/her bankcards and/or personal checks bearing personal and sensitivedata thus, avoiding the risks of theft or loss. The payment systemincludes a central system, a wireless device belonging to a customer, apayment card generated by the central system and sent to the customer,and an existing bankcard.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of this invention, as well as the invention itself,both as to its structure and its operation, will be best understood fromthe accompanying drawings, taken in conjunction with the accompanyingdescription, in which similar reference characters refer to similarparts, and in which:

FIG. 1 is a block diagram that illustrates a prior art payment systemand its privacy and security risks;

FIG. 2 is an illustration of privacy and security risks of personal datain prior art payment system;

FIG. 3 is a block diagram that illustrates features of the presentinvention payment system between a customer and a merchant;

FIG. 4 is a block diagram that illustrates features of the presentinvention payment system between two private parties;

FIGS. 5A-C are illustrations of use of a wireless device for a paymenttransaction having features of the present invention;

FIG. 6 is a block diagram that illustrates the use of a wireless devicefor withdrawing cash from an ATM having features of the presentinvention;

FIG. 7A illustrates a payment card having features of the presentinvention;

FIG. 7B illustrates a prior art bankcard that can be used with thepayment system having features of the present invention;

FIG. 8 illustrates a central system having features of the presentinvention; and

FIGS. 9A-B illustrate flow charts of the payment system operation,having feature of the present invention.

DESCRIPTION

Introduction

Five embodiments of a private and secure payment system are described.In the first embodiment a portable wireless-device is used by thecustomer to make a payment to a merchant and is illustrated withreference to FIGS. 3, 5 and 8. In the second embodiment a payment card,of the present invention, is used by the customer to make a payment to amerchant and is illustrated with reference to FIGS. 3, 7 and 8. In thethird embodiment, either a portable wireless device, or a payment cardof this invention, or a standard bankcard can be used by the customer tomake a payment to a merchant and is illustrated with reference to FIGS.3, 8 and 9A. In the fourth embodiment, a portable wireless device isused to make a private payment between two parties and is illustratedwith reference to FIGS. 4, 8 and 9B.

In the fifth embodiment, a portable wireless device is used to withdrawcash at an ATM and is illustrated with reference to FIGS. 5 and 6.

FIGS. 9A-B show the operational steps of the payment system. Theseembodiments offer privacy and security to the customer in paymenttransactions.

With initial reference to FIG. 3, a payment system apparatus 02facilitates private and secure payment transactions. The apparatus 02has a central system 10 (described later with reference to FIG. 8) thatworks in conjunction with a wireless device 12, a payment card 100, or abankcard 130. The payment system 02 of this invention does not requirethe customer to give any personal data including name, bankcard data,identification data such as driver license etc, to a merchant duringpayment transaction. The merchant cannot keep and track the customer'sbuying habits. The merchant does not have the burden of safeguardingcustomer sensitive data from theft and misuse. In many of theseembodiments, a customer need not carry his/her bankcard with him,avoiding loss or theft of bankcards.

In addition, a party A can make a payment to another private party Bwithout disclosing personal sensitive data as it happens when giving apersonal check for payment. Most personal checks are imprinted withname, address and driver license data and reveal customer bank and bankaccount number.

Additionally, many people use ATM, which require having an ATM card. Oneof the embodiments facilitates use of a wireless device in lieu of anATM card. This embodiment also helps party A perform money transfer toparty B via an ATM at a location where party A is not present but partyB is present. In addition no ATM card need to be carried, and manypeople carry a wireless device in the form of a cellular m telephone.

In summary, a customer may use a wireless device, a payment card or abankcard to conduct a private and secure payment transaction with amerchant. The customer may use the wireless device to conduct a privateand secure payment transaction between two parties. Also, using awireless device, a customer may withdraw cash at an ATM. The embodimentsas outlined above are described herein. The headings are provided forthe convenience of the reader.

First Embodiment Using Wireless Device

With reference to FIGS. 3, 5A-C and 8, a payment system 02 between acustomer 06 and a merchant 08 has a central system 10, a portablewireless device 12, and a merchant display terminal 14 with anidentification tag 16. The central system, the portable wireless deviceand the merchant terminal are on a global computer network 18. Theportable wireless device is used to effect a private and secure paymenttransaction from the customer to the merchant.

Wireless Device 12

The portable wireless device 12 may be a cellular telephone with ascreen and a keypad. Alternatively, it may be PDA with a wireless modem,which also has a display screen and a soft keypad.

The portable wireless device 12 has an interface that enables it toreceive merchant identification and payment amount at the time of thepayment transaction. The interface may consist of a numeric keypad witha screen, an optical-magnetic reading element or an infrared readingelement. The operation of the interface is described below.

FIG. 5A shows a wireless device 12, with a keypad 501A, a cursor control501C, menu function 501D on a screen 501B. It also shows a readingelement 502, which may be an optical character reading element. It alsoshows a reading element 504, which may be an infrared reading element.

The interface may consist of the customer manually entering the merchantidentification and the payment amount in the wireless device using thekeypad 501A and the screen 501B. Typically, the customer may not be atthe location where the merchant is located such as for a catalogmerchant, and is given the information by the merchant.

In addition, the interface may consist of a reading element 504receiving a wireless transmission of the merchant identification 520Aand a payment amount 24 from a merchant system 20. The transmission maybe wireless infrared commonly used in many remote control applicationssuch as a television. FIG. 5B in conjunction with FIG. 5A shows that themerchant system 20, with a serial interface 514, may be connected to aninfrared transmission device 512, which generates an area oftransmission 516 and which is read by element 504 of the wireless device12.

Typically, the customer is at a merchant checkout counter and is holdingthe device 12 in his hand enabling it to receive the transmission. Thesystem 20 can generate the data for the transmission at the time whenthe payment amount has been determined and is communicated to thecustomer to make a payment, allowing the customer to use the device 12to receive the transmission.

Alternatively, the interface may also have a reading element 502 thatscan-reads the identification tag 16 to read the terminal ID 520A and apayment amount 24 is manually entered into the device 12 by thecustomer. The reading element 502 is an optical type. The tag 16 is ofthe type 520A showing numerical characters that can be read by anoptical or magnetic reading element or it may be a bar code type 520B.

The identification tag 16 identifies the merchant, the store, and theterminal within the store for those merchants having more than one storeand having more than one payment terminal in a store. FIG. 5C shows amerchant identification tag 16 with numerical merchant identification520A and/or a bar code 520B.

Typically, when the customer is at merchant checkout counter, thecustomer is holding the device 12 in his/her hand and scans the tag 16to read the terminal identification. And then subsequently enters apayment amount.

After the merchant terminal identification and payment amount areentered by any one of the three interface means described above, theyare held in temporary memory of the device 12. Then the customer 06enters a Card Personal Identification Number (CPIN). A CPIN 856 is apersonal identification code that identifies the customer and/oridentifies the customer and one of the bankcards he/she wishes to usefor the payment transaction. As an illustration, the customer may haveCPIN 2301 that identifies a Visa card and 2302 that identifies a Mastercard, if he has two cards in the central system 10 that were pre-storedby the customer. If there is only one pre-stored card, there is only oneCPIN. The pre-stored accounts may include a plurality of cards such ascredit cards, debit cards, ATM cards or bank accounts.

The device 12 has an identification code 850, which uniquely identifiesthe device. The code 850 may be the telephone number assigned to thedevice 12 or the code 850 may be a identification identifying the chipinside the device 12 or the code 850 may be the frequency code used bythe device 12.

The device 12 has a payment function 26. The payment function 26 is afirmware function within the device 12, which may be activated by a menuitem “payment”, a keypad key combination such as an arrow key followedby a numeric key, or a special key for payment. The payment function 26,on being activated, creates an encrypted payment data record 28including at least the merchant terminal identification 862, the paymentamount 24, CPIN 856 and the device identification code 850 and transfersit over the global network to the central system 10.

The system 10 on receiving the data record 28, after decryption,identifies and verifies the customer and the particular bankcard he/shewishes to use for this payment, using the device identification 850 andthe CPIN 856. The customer may have a plurality of pre-stored accounts858 in the central system 10. The customer enters an accountidentification in the form of CPIN 856 into the wireless device 12,identifying a specific account 858 to be used for a payment transaction.The account identification may be a combination of personalidentification code verifying the customer and an account identificationcode and is collectively called CPIN 856 as described earlier.

Description Common to First, Second and Third Embodiment

The central system 10 assembles a payment transaction record 32 thatincludes the customer pre-stored bank account data 858, and submits thepayment transaction record to an automated clearing house 36 andreceives a payment authorization record 38. Subsequently the centralsystem 10 sends the payment authorization record 38 to the merchantdisplay terminal 14 using the terminal uniform resource locator 864 overthe global computer network.

The payment transaction record 32 submitted to the ACH 36 identifies acentral system business bank 40 for receiving payment amount from thecustomer bank 22. The ACH, depending upon the form of the bankcard orbank account is prior art bankcard authorization network for authorizingamounts from customer banks or a check automated clearinghouse used bybanks to clear checks with each other.

After completion of the payment transaction from the customer to themerchant, the merchant funds from a plurality of payment transactionsare in the bank 40. These merchant funds are transferred to the merchantbank account 48 on a periodic basis. To facilitate this fund transfer,the central system 10 has a merchant database 840 that maintains theterminal identification 862 and merchant identification 866 and amerchant bank account identification 868. The system 10 creates andsubmits a merchant payment record 46 to the ACH for transferring anaggregate amount from a plurality of payment transactions from thecentral system business bank 40 into the merchant bank account 48.

Refund from a Previous Payment Transaction

The central system 10 maintains a transaction database 842 catalogingeach payment transaction by a transaction reference 870, date and time872, an authorization reference 874, payment amount 876, customeridentification 854, merchant identification 866, and payment sequencenumber 857.

The merchant 08 is paying the customer 06 for a refund from a previouspayment transaction. A merchant refund terminal 66 is part of themerchant system 20, which is on the global computer network 18. Therefund terminal 66 may a web-based interface. The merchant 08 entersinto the refund terminal 66 a refund record 68 that includes, thepayment transaction reference 870 from a previous payment transaction,merchant identification 866, a refund-authorizing password, and a refundamount and then the refund record 68 is sent to the central system 10.

The central system 10 receives the refund record 68 from the merchantsystem 20 and verifies the elements of the record against thetransaction catalog 842, in particular, verifying the refund amount isless than or equal to the payment amount. The central system thencreates a refund ACH record 74 identifying the central system bank 40 asthe bank for receiving funds from the merchant bank account 48. Therefund record 74 is sent to the ACH 36 and an approval record 75 isreceived. The central system 10 then forwards the refund approval record75 to the refund terminal 66. The merchant system 20 having the refundterminal 66 is equipped with a printer capability 76 and prints a refundrecord. The central system 10 then creates a fund transfer record andsubmits to ACH 36 for crediting the funds from the central system bank40 to the customer bank account 22.

Customer Interface 03

The central system 10 provides a customer interface allowing theinterface to receive record 78 from customer 06 to create and enteraccount data, account identification code, and personal identificationcode. The interface additionally provides a record 80 to search andretrieve payment and refund transactions by type of transaction,transaction date, and merchant identification. It allows entry ofcustomer identifying data and search query and receiving the data sorequested. The interface is web-based and is prior art.

Merchant Interface 04

The central system 10 provides a merchant interface allowing theinterface to receive record 82 from merchant to enter merchantidentification, merchant account identification, and terminalidentification. The interface additionally provides a record 84 tosearch and retrieve payment and refund transactions by type oftransaction, by date, and transaction reference number. The interfaceallows entry of merchant identifying data, and a search query andreceiving the data so requested. The interface is web-based and is priorart.

Second Embodiment Using Payment Card

With reference to FIGS. 3, 7 and 8, the payment system 02 between acustomer 06 and a merchant 08 has a central system 10, a payment card100 with an encrypted card number 102; a merchant card reader 104 and amerchant display terminal 14. The central system, the card reader, andthe display terminal are on a global computer network 18, wherein thepayment card 100 is used to effect a private and secure paymenttransaction.

Payment Card 100

A payment card of this invention is not a bankcard and has norelationship to a bank or a banking entity in its operation and use.

With reference to FIG. 7A, the payment card 100 has front side 702 andback side 704. The front side 702 has an encrypted card number 102. Theencrypted card number resembles a bankcard number having 16 digits, thefirst four digits being in the form of bank identification identifying abank, 4 digits resembling an expiration date 708, and a name of the cardowner 710. In this invention, the identifying bank is the central systembank 40. The name 710 is any name chosen by the customer 06 and notnecessarily the real name. A title 706 identifies the payment card. Thebackside 704 can include a machine-readable area 712 such as a magneticstrip. The magnetic strip can include data in an encoded form.

With this design, if the payment card 100 fell into the wrong hands, itdoes not identify the card owner or any of the existing bankcard(s) ofthe customer 06.

With reference to FIG. 3, when the customer 06 is using the payment card100 at the location of the merchant 08, the payment card 100 can beswiped in a card reader 104. A Card Personal Identification Number(CPIN) is entered 106 into the card reader 104 by the customer. Themerchant identification and a payment amount is entered into the cardreader by the merchant 08, and a data record 108 including at least theforegoing data and the encrypted card number 102 is transferred over theglobal network 18 to the central system 10.

The central system 10 decrypts the payment card number 102 to identifythe customer identification 854. FIG. 7C illustrates an approach of theSecurity Function 830 that takes encrypted card number 102 anddetermines the customer identification 854. At step 720, the card number102 along with its expiration date 708 and a CPIN 856 that is entered bythe customer 06 is received by the system 10. At step 722, the 16 digitsof the card number 102 are parsed into four 4-digit numbers. In thesecurity function 830, from table A 732, four offset numbers 760 thatcorrespond to the 4-digit expiration date 708 are read. Table A 732shows the offset numbers 760 that correspond to the expiration date 708.At step 724, the offset numbers 760 are added to each of the four4-digit numbers. At step 726, the modified four 4-digit numbers arecombined to form a customer identification number 854. At step 728,using the customer identification number 854 and the CPIN 856 fromcustomer database 838B the particular bankcard data 858, which thecustomer wishes to use for this payment transaction is obtained.

Third Embodiment Using Bankcard

With this embodiment, an existing bankcard 130 of the customer 06 may beused by the customer in conjunction with a CPIN 856 for a paymenttransaction. However, this payment transaction is not identified in thecustomer's bank 22 records as originating from a merchant to whom thepayment is being made. Thus the use of an existing bankcard 130 inconjunction with a CPIN 856 offers privacy and security to the customerduring a payment transaction with an existing bankcard of the customer.

With reference to FIGS. 3, 7 and 9A, a payment system between a customer06 and a merchant 08 has a central system 10, in conjunction with aportable wireless device 12, a payment card 100 with an encrypted cardnumber 102, a standard bankcard 130, a merchant card reader 104 and amerchant display terminal 14 with an identification tag 16. The centralsystem, the portable wireless device, the merchant card reader and thedisplay terminal are on a global computer network. The customer selectseither the portable wireless device, the payment card, or the bankcardto effect a payment transaction to the merchant.

Bank Card 130

FIG. 7B illustrates a bankcard 130 that can be used in conjunction withthe present invention. The bankcard 130 can be a debit card, a creditcard, a check card, or another type of card already obtained by thecustomer. The bank card 130 can include private data of the customer 06including the name, number of the bank card, expiration date of thebankcard 130 and signature as illustrated on front and back sides 130Aand 130B of the bank card 130.

The bankcard 130 is swiped in the card reader 104 and a card personalidentification number (CPIN) 856 is entered into it by the customer. Themerchant identification/terminal identification and a payment amount isentered into the card reader by the merchant 08; and a data recordincluding at-least the foregoing data and the bankcard number istransferred over the global network to the central system 10.

The central system 10, with the bankcard number 130 and the CPIN 856 andby searching the database 838B, is able to verify the customer and alsoto identify pre-stored remainder bank card data 858 and assemble apayment transaction record. FIG. 9A steps 922 to 936 describe how thecentral system 10 separates a bankcard 130 from a payment card 100.

Fourth Embodiment Using Either a Wireless Device, a Payment Card or aBankcard

With reference to FIGS. 4 and 8, a payment system between two partieshas a central system 10, a portable wireless device 12 belonging toparty A 200, the central system 10 and the portable wireless device 12are on a global computer network 18. The portable wireless device 12 isused to effect a private and secure payment transaction to private partyB 202. At time of payment transaction from party A to party B, a party Bidentification 204 and a payment amount 205 are entered into device 12.The party B identification may be the party B's telephone number 855.Party identification in the form a telephone number is preferred as itis the most widely familiar structure of numbers. In actual use it maybe a real telephone number of the party or a made up telephone number.Alternatively other forms of identification may be used.

On activating a payment function 226 in the wireless device 12, a datarecord 208 including at least the party B identification 855, thepayment amount 205 and a portable wireless device identification code850 is transferred over the global network 18 to the central system 10.The wireless device identification code is a combination of apre-programmed identification code and a customer entered CPIN 856 toidentify which card or bank account 858 the payment is being made from.

The device 12 has a payment function 226. The payment function 226 is afirmware function within the device 12, which may be activated by a menuitem called “payment”, a key pad key combination such as an arrow keyfollowed by a numeric key, or a special key for payment. The paymentfunction 226 on being activated creates an encrypted payment data record208 including at least the party B's identification 855, the paymentamount, CPIN 856 and the device identification 850 and transfers it overthe global network to the central system 10.

The central system 10 has two database 838A and 838B that identify partyA's identification and a party B's bank account identification. Thesystem 10 assembles a payment transaction record 210 including at leastthe party A pre-stored bank account data 858, payment amount andidentifies a central system business bank 40, submits the paymenttransaction record 210 to an automated clearing house 36 and receives apayment authorization record 214.

The central system 10 using the database 838B identify Party B'sidentification 855 and a party B's bank account identification 858. Thesystem 10 assembles a payment transaction record 218 including at leastparty B 202 pre-stored bank account data, payment amount and identifiesthe central system bank 40 and submits the payment transaction record218 to an automated clearing house 36 and receives a paymentauthorization record 220.

The central system 10, having party A and party B identifications andtheir e-mail addresses 860 in database 838B sends a e-mail notification225 of the payment authorization to the party A and e-mail notification224 to party B's e-mail address.

In this embodiment party A has made a private and secure payment toparty B without either party A or party B knowing each other's personaland sensitive data. Conversely party B can make a similar payment toparty A. Party A or B need to know each other's telephone number or apseudo telephone number to make such a private payment

Fifth Embodiment Using Wireless Device to Withdraw Cash from an ATM

This embodiment of the payment system 10 enables the use of an ATM towithdraw cash without the need to carry an ATM card. Privacy andsecurity is provided to a user because the ATM card which identifies theowner by name and card number, need not be carried on the person.

With reference to FIGS. 6 and 8, a cash withdrawal system between aparty A 300 and an ATM machine has a central system 10, a portablewireless device 12 belonging to customer 300, an ATM machine 333 and aATM identification tag 334. The central system 10, the portable wirelessdevice 12, and the ATM 333 are on a global computer network 18 and theportable wireless device 12 is used to effect a cash withdrawaltransaction from the ATM 333.

The portable wireless device 12, with a built-in reading element 502, atthe time of a withdrawal transaction, reads the terminal identificationtag 334 and a withdrawal amount 305, and a CPIN 856 is entered into it305. A withdraw function 326 in the wireless device is activated,enabling a data record 308 including at least the ATM terminalidentification, the withdrawal amount, a portable wireless deviceidentification code and the CPIN to be transferred over the globalnetwork to the central system 10.

The device 12 has a withdrawal function 326. The withdrawal function 326is a firmware function within the device 12, which may be activated by amenu item “withdraw”, a key pad key combination such as an arrow keyfollowed by a numeric key, or a special key for payment. The withdrawfunction 326 on being activated creates an encrypted withdraw datarecord 308 including at least the ATM terminal identification 334, thewithdraw amount 304, CPIN 854 and the device identification code 850 andtransfers it over the global network to the central system 10.

The central system 10 assembles a withdraw transaction record 324including the customer pre-stored bank account data 858, and submits thewithdraw transaction record to the ATM system 333, enabling the ATM toprocess and disburse cash amount to the party 300. The ATM 333, knowingthe means of arrival of ATM card data from the central system 10 asopposed to from an ATM card insertion, suppresses printing of a paperrecord for the ATM customer, because an e-mail notification 325 is sentto the party 300 by the central system 10.

Central System 10

Referring to FIG. 8, the central system 10 includes (i) a system storagedevice 826, (ii) a system operating system 802 stored in the paymentsystem storage device 826, (iii) a system program 804 stored in thesystem storage device 826, (iv) and a system processor 830 connected tothe payment system storage device 826.

The payment system processor 830 can include one or more conventionalCPU's. The payment system processor 830 can be capable of high volumeprocessing and database searches.

The payment system storage device 826 can, for example, include one ormore magnetic disk drives, magnetic tape drives, optical storage units,CD-ROM drives and/or flash memory. The payment system storage device 826also contains a plurality of databases used in the processing oftransactions pursuant to the present invention. For example, asillustrated in FIG. 8, the system storage device 826 can include amerchant database 840, and a customer database 838 and a transactiondatabase 842.

The system 10 includes a system network interface (not shown) thatallows the system 10 to communicate with the customer 06. Conventionalinternal or to external modems may serve as the system networkinterface. In one embodiment, the system network interface is connectedto the customer interface 03 on a global network 18.

A merchant network interface (not shown) allows the merchant 08 tocommunicate with the system 10. Conventional internal or external modemsmay serve as the merchant network interface. In one embodiment, themerchant network interface 04 is connected to the system 10 on theglobal network 18.

The system 10 interfaces with an ACH/bank card authorization network 36.The ACH/bankcard authorization network 36 is a computer system thatprocess data from an existing bankcard or an automated clearing house toprocess payments between banks.

The payment system processor 830 is operative with the system program804 to perform the Security Function 806, Payment Processing Function808, Customer Interface function 810, Merchant Interface function 812,ACH interface function 814, and payment card function 816.

Central System Program 806

The central system program 806 is operative with the central systemprocessor 830 to provide the functions of (i) Security Function 806,(ii) Payment Processing Function 808, (iii) Customer Interface Function810, (iv) Merchant Interface Function 812, (v) an ACH Interface function814, (vi) and a payment card function 816. Further, the system program804 is operated with the payment system processor 830 to perform thetasks of the central system 10 provided herein.

The Security Function 806 performs the tasks of determining andverifying the customer identification and the specific bank account whenthe customer initiates a transaction using either a wireless device 12,a payment card 100, or a bankcard 130. For a payment card 100, the logicis as illustrated earlier with reference to FIG. 7C.

The payment processing function 808 performs the tasks of creatingpayment records and notification records that are transmitted to andfrom the central system 10. FIGS. 3, 4, and 6 explain the records thatare transmitted from and to the central system.

The customer Interface function 810, via a web interface, performs thetasks of permitting the customer to open an account, enter data and tosearch and retrieve his transaction data.

The merchant Interface function 812, via a web interface, performs thetasks of permitting the merchant to open an account, enter data and tosearch and retrieve his transaction data.

The ACH interface function 814 performs the tasks of sending andreceiving transaction records from and to the prior art ACH/bankcardprocessing network 36.

The payment card function 816 performs the tasks of creating, printingand mailing the payment card 100 of this invention to the customer 06 onhis request via the customer interface function 810. Another businessexperienced in printing bankcards may be utilized to actually print thepayment card 100 and mail them to the customer 06.

Customer Database 838

With reference to FIG. 8, the customer database 838 within the centralsystem 10 contains private data specifically related to the customer 06that is transferred to the system 10 from the customer. The private datarelated to the customer 06 can be separated and stored in at least twoseparate sub-databases, namely, (i) an identifier sub-database 838A, and(ii) existing bank card data sub-database 838B. The sub-databases areexplained below.

Identifying Sub-Database 838A

This database contains the wireless device identifier 850, payment cardnumber 852 and a customer identification number 854. This database isused by security function 806 on first contact with the central system10, either by a wireless device 12 or payment card 100, to identify acustomer identification 850.

Existing Bank Card Data Sub-Database 838B

This database maintains private data of the customer anchored by thecustomer identification number 854. The customer identifier for privateparty B is a telephone number 855. The other data is CPIN 856, Bankaccount data 858 and e-mail address 860. Multiple CPIN and bank accountdata for each customer may be maintained allowing a customer to use anyone of his/her accounts whether they be checking accounts, debit cardaccounts or credit card accounts. The payment sequence number 857 isused to identify one or more payment cards or bank accounts of thecustomer. The bank account data may contain customer name, banknumber/routing number, card or account number and any specific PIN codesfor that account.

The customer 06, party A 200, party B 202, party 300 may enter data intothis database data via a web interface (not shown).

Merchant Database 840

This database maintains data on the merchants who use the payment system02. There are two databases, one is a merchant identifying sub-database840A and second is merchant bank account data sub-database 840B.

The sub-database 840A maintains data on each of the merchant displayterminals 862, a terminal URL 864, and a merchant identification number866. The terminal identification identifies a terminal of the merchantand is the one present on the terminal identification tag and is the onetransferred to the wireless device 12. The terminal URL 864 is used tosend a payment record to the terminal over the global computer network.

The sub-database 840B maintains data on the merchant 857 and merchantbank account 868 allowing funds from payment transactions to be directedto the merchant bank 48. The merchant data 857 may include merchant nameand address.

The merchant 08 may enter data into this database data via a webinterface (not shown).

Transaction Database 842

This database logs all payment transactions by a transaction reference870, date/time of transaction 872, merchant terminal identification 862from which the transaction originated, merchant ID 866, amount 876,authorization code 874 received from the ACH/card network and customeridentification 854 and the sequence number of the payment account usedfor this transaction 857.

This database may be searched by the customer 06, via a search queryrecord 80, to display payment transactions by a search criterion such asmerchant identification and date/time ranges via a web interface (notshown).

This database may be searched by the merchant 08, via a search queryrecord 82, to display payment transactions by a search criterion such asterminal identification and date/time ranges via a web interface (notshown).

Operation

The operation of the apparatus 02 and central system 10 for a paymenttransaction between a customer and a merchant can be further understoodwith reference to the flow chart illustrated in FIG. 9A. Importantly,the order of some or all of the steps can be varied. Further, not all ofthe steps outlined below are necessary to perform a transaction pursuantto the present invention.

At step 900, the customer 06 is at a merchant 08 ready to make apayment. At step 902, the customer 06 chooses from a wireless device 12or a card payment choice. At step 904, the customer has selected thewireless device 12 for payment. At step 908, the customer 06 faces thereader element 504 of the wireless device 12 to the merchant system 20.The merchant terminal identification 862 and payment amount 852 arereceived wirelessly via infrared received into the wireless device 12.Alternatively, the customer may scan the identification tag 16 usingreading element 502 and manually enter the payment amount into thedevice 12. If the customer 06 is not at the location of the merchant 08,the customer may manually enter both the terminal identification 862 andpayment amount 852 into the device using its keypad 501A.

At step 910, the customer enters CPIN 854 for a specific existingbankcard and selects payment function 26. At step 912, the device 12sends the payment record 28 to the central system. At step 914, thesystem receives record, decodes device ID 850 to find customer ID 854,verifies CPIN 856 and identifies the specific card 858 chosen bycustomer 06 for this payment transaction. At step 906, the customer haschosen card for payment.

At step 922, customer swipes card in the reader 104. At step 924,customer enters CPIN 856. At step 926, card reader 104 sends cardnumber, CPIN, amount, and merchant identification to system 10. At step928, system 10 determines type of card based on the first four digits aseither a bankcard or a payment card. At step 930, a payment card isdetermined. At step 932, encrypted card number 102 is decoded to findcustomer ID 854 and verify CPIN 856 to identify the specific card 858chosen for payment. At step 934, the system determines a bankcard hasbeen chosen. At step 936, the system verifies card owner by the CPIN 856and bankcard 858.

At step 916, the system 10 creates a transaction reference 870,assembles specific card data of name, card number, expiration date, andmerchant identification as the central system business bank 40 and sendsthe payment transaction to the ACH 36. At step 918, system 10 receivesauthorization record, saves the record in the transaction database 842,and forwards the approval data to merchant display terminal. At step920, the terminal receives approval data, letting the merchant 08 knowthat the transaction has been approved.

The operation of the apparatus 02 and central system 10 for a paymenttransaction between a party A and party B can be further understood withreference to the flow chart illustrated in FIG. 9B. Importantly, theorder of some or all of the steps can be varied. Further, not all of thesteps outlined below are necessary to perform a transaction pursuant tothe present invention.

At step 940, Party A 200 wishes to make a private payment to party B 202and inquires party B's telephone number. At step 942, Party A takes outits wireless device 12 and enters party B identification (telephonenumber), a payment amount, a CPIN and activates payment function 226. Atstep 944 the device 12 creates a payment record 208 and sends to centralsystem 10. At step 946, central system 10 receives the data, decodesdevice Identification to find the customer identification number andverifies CPIN and identifies the specific account chosen by party A 200for payment. At step 948 the central system 10 creates transactionreference, assembles specific account data of party A, central systembank identifier 40, amount and sends to the .ACH and receives transferof funds to the bank 40. At step 950 the central system 10 createsanother transaction reference, assembles specific account data of partyB, central system bank identifier 40, and amount and sends to the ACH toeffect transfer of funds to party B's bank account. At step 952, thesystem 10 saves in transaction database 842 the data associated with thecompletion of transfer of funds and sends notification e-mail 225 toparty A 200 and to party B 224.

In summary, the payment system 02 allows the customer 06 to maintain onepayment card 100 in lieu of many bankcards to facilitate private andsecure payments to a merchant 08. Alternatively, the payment system 02allows the customer 06 to maintain a wireless device 12 in lieu of manybankcards to facilitate private and secure payments to a merchant 08.Alternatively, the payment system 02 allows the customer 06 to usehis/her existing bankcards 130 to facilitate private and secure paymentsto a merchant 08. Also the payment system 02 facilitates private andsecure payments between two private parties. Additionally the paymentsystem 02 allows a private party to make a cash withdrawal at an ATMwithout the use of an ATM card. The payment system 02 provides privateand secure payment transactions.

While the particular apparatus 02 as illustrated herein and disclosed indetail is fully capable of obtaining the objective and providing theadvantages herein before stated, it is to be understood that it ismerely illustrative of the presently preferred embodiments of theinvention and that no limitations are intended to the details ofconstruction or design herein shown other than as described in theappended claims.

What is claimed is:
 1. A secure payment system between a customer and amerchant, comprising: a wireless device of the customer that receives apartial payment authorization transaction record from a sales terminalof the merchant to include at least a merchant terminal identificationand a payment amount to facilitate payment transaction via a customerportable wireless device from the customer to the merchant.
 2. Thesystem as in claim 1, comprising: the device has a receive sensor toreceive the partial transaction record from the sales terminal eithervia a short rf or optical infrared.
 3. The system as in claim 1,comprising: the device has a function that enables activating a paymenttransaction function in the device to receive a partial paymentauthorization record from the sales terminal of a merchant.
 4. Thesystem as in claim 3, comprising: the device function requires entry ofa personal code of the customer and transmits the partial transactionrecord to include, at least the merchant terminal identification, and apayment amount to a third party payment system that pre-stores customerbankcard data.
 5. The system as in claim 1, comprising: the devicereceives the partial transaction record that is specific to a salestransaction of the customer at the sales terminal of the merchant. 6.The system as in claim 1, comprising: the device has entry means for thecustomer for manually entering the merchant identification and thepayment amount in the wireless device using the keypad and the screen.7. The system as in claim 1, comprising: the device has anidentification code, which uniquely identifies the device to the centralsystem.
 8. The system as in claim 1, comprising: the device 12 has apayment function, activated by a menu item “payment”, a keypad keycombination such as an arrow key followed by a numeric key, or a specialkey for payment.
 9. The system as in claim 8, comprising: the paymentfunction, on being activated, creates an encrypted payment data recordincluding at least the merchant terminal identification, the paymentamount, a personal code and the device identification code and transfersit over the global network to the central system.
 10. The system as inclaim 1, comprising: the device receives from the central system anotification of the payment approval record.
 11. A method of securepayment between a customer and a merchant, comprising the step of:receiving by a wireless device of the customer a partial paymentauthorization record from a sales terminal of the merchant to include atleast a merchant terminal identification and a payment amount tofacilitate payment transaction via a customer portable wireless devicefrom the customer to the merchant.
 12. The method as in claim 11,comprising the step of: having by the device has a function that enablesactivating a payment transaction function in the device to receive apartial payment authorization record from the sales terminal of amerchant.
 13. The method as in claim 11, comprising the step of:requiring by the device function entry of a personal code of thecustomer and transmitting the partial transaction record to include, atleast the merchant terminal identification, and a payment amount to athird party payment system that pre-stores customer bankcard data. 14.The method as in claim 11, comprising the step of: having a receivesensor in the device to receive the partial transaction record from thesales terminal either via a short rf or optical infrared.
 15. The methodas in claim 11, comprising the step of: the receiving by the device isspecific to a sales transaction of the customer at the sales terminal16. The method as in claim 11, comprising the step of: having entrymeans in the device for the customer for manually entering the merchantidentification and the payment amount in the wireless device using thekeypad and the screen.
 17. The method as in claim 11, comprising thestep of: identifying the device with an identification code, whichuniquely identifies the device to the central system.
 18. The method asin claim 11, comprising the step of: having by the device a paymentfunction, activated by a menu item “payment”, a keypad key combinationsuch as an arrow key followed by a numeric key, or a special key forpayment.
 19. The method as in claim 11, comprising the step of:activating the payment function, creates an encrypted payment datarecord including at least the merchant terminal identification, thepayment amount, a personal code and the device identification code andtransfers it over the global network to the central system
 10. 20. Themethod as in claim 11, comprising the step of: receiving by the devicefrom the central system a notification of the payment approval record.